Dass schnellere Webseiten zu höheren Konversionsraten und unterm Strich glücklicheren Usern führen, dürfte heute niemand ernsthaft überraschen. Im Hause Google ist man allerdings immer darum bemüht, den Benutzern noch bessere Erlebnisse zu liefern. Schon aus diesem Grund gibt es nun eine Gruppe neuer Metriken, die eine neue Sichtweise auf Geschwindigkeitsmessungen von Web-Apps ermöglichen.

Gleich zu Beginn: Die als Core Web Vitals bezeichneten Metriken sind auch für Ihre Applikation relevant. Das liegt – brutal gesagt – daran, dass Google wie auf der I/O angekündigt die Web-Vitals-Ergebnisse über kurz oder lang in die Berechnung des PageRank einfließen lassen wird. Daraus folgt, dass ein Webdesigner, der sich nicht an den Core Web Vitals orientiert, über kurz oder lang schlechtere Positionierungen seiner Inhalte in den Suchergebnissen hinnehmen muss.

Wo kommt es her?

Beginnen wir mit der Informationsquelle: Core Web Vitals sind per se Teil des Google-Webmaster-Portals, das seit längerer Zeit auf Opfer wartet [1]. Ins Rampenlicht gerieten diese Metriken allerdings erst im Rahmen der dieses Mal aufgrund der Coronapandemie als virtuelles Event abgehaltenen Google I/O, auf der sie sowohl im Rahmen der Keynote als auch einiger dedizierte Vorträge im Detail erläutert und vorgestellt wurden. Am interessantesten ist dabei die Frage, wie Google die für die Berechnung der Suchmaschinenrankings verwendeten Werte erhebt. Wenn Sie ob des Einflusses „kurzer Serverausfälle“ auf den PageRank Angst bekommen, können wir an dieser Stelle Entwarnung geben. Der im Allgemeinen exzellent informierte Branchennewsdienst Search Engine Journal hat zu diesem Thema Informationen von Google eingeholt [2]. Im Original lautet die relevante Aussage wie folgt: „… the data that we show in Search Console is based on the Chrome User Experience report data which is aggregated over those 28 days. So that’s the primary reason for the delay there. It’s not that Search Console is slow in processing that data or anything like that …“

Google beschafft die Informationen offensichtlich aus dem anonymen Datenupload, die diesbezüglich eingestellte Chrom-basierte Browser periodisch nach Hause schicken. Diese Informationen werden von Google danach gesammelt und über einen 28 Tage dauernden gleitenden Durchschnitt gemittelt. Daraus folgt einerseits, dass kurzfristige Performanceprobleme nicht sofort zu einer massiven Verschlechterung der Ergebnisse führen. Andererseits gilt aber auch, dass eine durchgeführte Verbesserung bei der Infrastruktur erst mit Verzögerung in Form besserer Suchrankings wirksam wird.

Das bedeutet allerdings nicht, dass Sie nicht schneller Rückschlüsse über die zu erwartenden Ergebnisse erhalten können. Google stellt Entwicklern diverse Werkzeuge zur Analyse der Beziehung zwischen Core Web Vitals und Ihrem Webprojekt zur Verfügung – wir werden Sie später in diesem Artikel, nach der Besprechung der eigentlichen Metriken, im Detail vorstellen.

Metrik eins: Largest Contentful Paint

Obwohl Google in Präsentationen immer wieder darauf hinweist, dass sich die Zusammensetzung der Core Web-Vitals-Benchmarks permanent ändert, gibt es zum Zeitpunkt der Drucklegung dieses Hefts drei Standardmetriken, deren Optimierung erforderlich ist. Kandidat Numero eins hört auf den Namen Latest Contentful Paint und wird in der Fachliteratur mit LCP abgekürzt. Sei dem, wie es sei: Über die Frage, was einen schnellen Start einer Applikation darstellt, lässt sich hervorragend diskutieren. Samsung nutzte in Bada einst Splash-Screen-Grafiken, die das Betriebssystem während des eigentlichen Applikationsstarts einblendete, mit Android 12 kopiert Google diese Vorgehensweise zu einem gewissen Grad. Witzigerweise gilt hier das Prinzip des quod licet Iovi, non licet bovi – in der Beschreibung der Metrik spricht Google explizit davon, dass Splash Screens für die Bewertung der Geschwindigkeit einer Webseite eine denkbar schlechte Metrik seien. Ursache dafür ist, dass der Benutzer ja mit den auf der Webseite angezeigten Inhalten interagieren möchte, und nicht wirklich den Splash Screen sehen will. Als Kernmetrik findet Google das Aufscheinen des „visuell schwersten“ Elements nützlicher; zur Veranschaulichung der Vorgehensweise empfiehlt sich Abbildung 1, das von Google bereitgestellte Bild zeigt anhand zweier bekannter Webseiten, wann der als LCP bezeichnete Hauptrenderingprozess abgeschlossen ist.

Abb. 1: Der LCP betrifft immer das visuell schwerste Element [3]

Alle News zu Web Design, UX und Digital Marketing

An dieser Stelle ist die Frage angebracht, welche Markup-Elemente von Google als Kandidaten für das größte angezeigte Element herangezogen werden können. Wie bei den restlichen Core Web Vitals gilt auch hier, dass sich Google permanente Änderungen zum Nachteil der Webdesigner offenhält – zum Zeitpunkt der Drucklegung werden die folgenden fünf Elementarten in die Analyse einbezogen:

<img>
<image>, wenn Kind eines <svg>
<video>
Element mit per url() geladenem CSS-Hintergrund
Block-level Elements, die Kinder mit Text haben

Interessant ist in diesem Zusammenhang noch, welche Werte Google als gut bezeichnet. Zum Zeitpunkt der Drucklegung gilt dabei – siehe auch Abbildung 2 –, dass eine Webseite den LCP idealerweise innerhalb von 2,5 Sekunden hinter sich bringen muss.

Abb. 2: Wer Googles Ansprüchen genügen möchte, muss beim Rendern der Inhalte schnell sein [3]

LCP, zur zweiten

Nach der Deklaration dessen, was die Metrik LCP darstellt, können wir uns ihrer Optimierung hingeben. Aus der Logik folgt, dass die LCP auch von allgemeinen Verbesserungen profitiert. Wer beispielsweise einem (notorisch langsamen) WordPress-Server auf verschiedene Arten Caching spendiert oder Bilder in ein CDN auslagert, ermöglicht nebenbei auch schnelleres Laden der diversen Inhalte. Unterm Strich gibt es einige spezifische Optimierungen für LCP, die Google (grob) zusammenfasst [4]. Ein interessanter Aspekt betrifft das Laden von Ressourcen. Da heutige Browser so gut wie immer auf Mehrkernprozessoren arbeiten und Internetverbindungen zudem immer latenzbehaftet sind, dürfte es nicht ernsthaft verwundern, dass so gut wie alle Rendering-Engines mehrere Elemente gleichzeitig verarbeiten. Dies betrifft explizit auch das DNS-Vorladen, die folgenden beiden rel-Attribute geben den Engines Hinweise darauf, dass die jeweiligen Verweise von besonderer Bedeutung für die Performance der Webseite sind und deshalb spezielle Behandlung benötigen:

<head>
  ...
  <link rel="preconnect" href="https://example.com" />
  <link rel="dns-prefetch" href="https://example.com" />
</head>

Ein preconnect-Link sorgt dabei auf unterstützten Browsern dafür, dass die Engine sofort, also beim Antreffen der Inhalte, eine Verbindung zum jeweiligen Zielserver aufnimmt. Diese lässt sich danach ohne den TCP-inhärenten Verbindungsaufbau zum Herunterladen von Ressourcen verwenden. dns-prefetch ist eine langsamere Variante, die den Browser nur anweist, die Domain der jeweiligen Ressourcen sofort aufzulösen. In beiden Fällen gilt, dass der eigentliche Ressourcenzugriff dann durch Vorhererledigung des Housekeepings schneller erfolgt. Ein weiterer denkbarer Weg zur Beschleunigung von LCP ist das schnellere Laden diverser Ressourcen. Das preload-Attribut lässt sich auf mehrerlei Art und Weise zum Beschleunigen des Resolve-Prozesses einbinden, die folgenden Zeilen illustrieren gangbare Methoden:

<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />

Da Google die Erhebung der Performancedaten zum Zeitpunkt der Drucklegung ausschließlich in auf der Chrome-Engine basierenden Browsern durchführt, sollte aus der Logik folgen, dass die Nutzung ihrer Performancebeschleunigungsmethoden hohe Priorität genießt. Ab Chrome 73 lassen sich Responsive Images mit dem Payload-Tag kombinieren. Ein Responsive Image [5] ist dabei ein Image-Tag, das nach folgendem Schema eine Gruppe von für die jeweiligen Bildschirmauflösungen optimierte Ressourcen bereitstellt:

<img src="small.jpg" srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 1500w" alt="…">

Der Browser kann so anhand seiner Gegebenheiten entscheiden, welche Version der Ressourcen er benötigt – das unnötige Herunterladen hochauflösender Bilder beispielsweise auf Geräten mit niedriger Bildschirmauflösung entfällt, was Serverressourcen und Übertragungszeit einspart. Eine weitere Maßnahme, die allerdings (teilweise) auf Kosten der Usability geht, ist die Verlangsamung bzw. Deaktivierung mancher Webseitenelemente beim Antreffen langsamer Verbindungen. Ein im Bezug auf LCP optimales Beispiel dafür wäre der nach folgendem Schema mögliche Austausch eines Hintergrundvideos, wenn man eine Mobile-Internetverbindung erkennt – dem Mobile-User wird in diesem Fall, Google sei Dank, ein statisches Bild angezeigt:

if (navigator.connection && navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // Load video
  } else {
    // Load image
  }
}

Für derartige Optimierungen bietet Google eine Gruppe von Hilfsfunktionen an. Die folgenden vier Attribute sind dabei besonders wichtig, sie liefern Informationen über die Leistungsfähigkeit des Endgeräts, die Art der Internetverbindung und darüber, ob der Benutzer eine eventuell vorhandene Datenverbrauchsreduktionsfunktion aktiviert hat:

navigator.connection.effectiveType
navigator.connection.saveData
navigator.hardwareConcurrency
navigator.deviceMemory

Latenz bei der Eingabeverarbeitung

Als Netscape die ersten Versionen von JavaScript spezifizierte, ging man davon aus, ein Werkzeug für die gelegentliche Ereignisverarbeitung zu bauen – klickt der Benutzer auf einen Knopf, kann man ein problematisches Textfeld rot einfärben. Dass das Programmiersystem jemals zur Realisierung komplexer Webapplikationen geeignet sein würde, war für das Entwicklerteam damals nicht vorstellbar. Witzigerweise leben wir heute in einer Zeit, in der das direkte Verdrahten eines JavaScript-Handlers mit einem DOM-Objekt mehr die Ausnahme als die Regel darstellt. Aufgrund diverser Architektur und Hauptthread-blockierender Prozesse ist es vorstellbar, dass zwischen dem Anklicken eines Steuerelements und der Aktivierung seines Event Handlers erhebliche Mengen Zeit ins Land gehen – ein Problem, dem Google über die als FID bezeichnete Metrik auf die Pelle rücken möchte. Hinter dem Begriff FID verbirgt sich dabei übrigens der Begriff First Input Delay, Abbildung 3 zeigt, welche Latenzen für das Erreichen einer guten Bewertung aus Sicht von Google erforderlich sind.

Abb. 3: Möchte die Webseite eine gute Bewertung, muss sich der Event Handler sputen [3]

Googles für den PageRank relevante Datenerhebung beschränkt sich dabei auf das erste Ereignis. Das deshalb, weil der Hauptthread eines Browsers im Rahmen der erstmaligen Initialisierung einer Webapplikation – denken Sie an die diversen Frameworks – höheren Belastungen ausgesetzt ist. Interessanterweise ist das Nichteinschreiben von Event Handlern kein Weg, um einen perfekten FID-Score zu erreichen. Google bewertet nämlich nicht nur mit einem on*-Handler verdrahtete Ereignisse, sondern auch alle gewöhnlichem Klickereignisse, die einen der folgenden Steuerelementtypen zum Ziel haben:

<input>
<textarea>
<select>
<a>

Google weist in der Dokumentation der FID-Metrik an mehreren Stellen darauf hin, dass die von FID gelieferten Ergebnisse von User zu User unterschiedlich sind – klickt ein unglücklicher Kandidat während der Verarbeitung einer komplizierten JavaScript Payload, vergeht natürlicherweise mehr Zeit, bis der Arbeitsthread des Browsers für die Verarbeitung dieses Klickereignisses bereitsteht.

Optimierung von FID

Wie im Fall ihrer Kollegin gilt auch für FID, dass Google metrikspezifische Optimierungsrichtlinien zur Verfügung stellt, die sich unter [6] abrufen lassen. Im Bereich des FID geht der Trend dabei in Richtung der Reduktion bzw. der Verzögerung des Parsings von JavaScript-Dateien. Dahinter steht der Gedanke, dass der Browser (normalerweise) jedes eingetroffene script-Tag synchron verarbeitet. Das kann zum in Abbildung 4 gezeigten Problem führen, bei dem ein Lade- oder Parsing-Prozess die Verarbeitung von Eingabeereignissen blockiert.

Abb. 4: Rennt der Parser, so steht die Webseite [3]

Die Nutzung eines Web Workers ist in diesem Bereich in vielen Fällen ein attraktiver Workaround, ermöglicht die Komponente doch das In-den-Hintergrund-Schieben mehr oder weniger beliebiger JavaScript Payloads. Neben allgemeinen Optimierungen – der schnellste JavaScript-Code ist der, der nicht geparst werden muss – bietet sich die Anpassung der script-Tags nach folgendem Schema an:

<script defer src="..."></script>
<script async src="..."></script>

Insbesondere im Fall von Analyse- und sonstigen Diensten lässt sich durch Nutzung der hier gezeigten Attribute ein verzögertes Laden der jeweiligen Skriptdateien anweisen. Dass Ihre Logik in diesem Fall allerdings darauf achten muss, mit den jeweiligen Funktionalitäten erst nach dem „erfolgreichen Laden“ der jeweiligen Module zu interagieren, folgt aus der Logik. Der Autor muss an dieser Stelle noch darauf hinweisen, dass die FID-Metrik ausschließlich die Zeit misst, die bis zum Start der Ereignisverarbeitung ins Land geht – die eigentliche Laufzeit des Event Handlers ist nicht berechnungsrelevant. Es spricht also nichts dagegen, im Fall einer noch nicht vorhandenen Funktionalität ein Ereignis zu queuen, das Sie später Google-freundlich und neutral zur Abarbeitung bringen.

Dynamische Bewegung ist übel

Mit der dritten Metrik CLS (ausgeschrieben verbirgt sich dahinter der Begriff Cumulative Layout Shift) beißt sich die JavaScript-Katze bis zu einem gewissen Grad in den Schwanz. Einer der ursprünglichen Anwendungsfälle der Programmiersprache war ja das Realisieren von Animationen in sonst statischen Webinhalten. Wie so oft sind gut und gut gemeint zwei paar Schuhe – in der Praxis kommt es nämlich immer wieder zu Problemwebseiten, die nach dem in den Abbildungen 5 und 6 illustrierten Schema aufgebaut wurden.

Abb. 5: Erst klickt der User auf die Option „No“, …

Abb. 6: … um sich nach dem Einblenden des Informationsbands mit dem Knopf „Yes“ konfrontiert zu finden [3]

Alle News zu Web Design, UX und Digital Marketing

Mit CLS möchte Google derartigen Tanzwidgets den Krieg erklären. Spezifisch ist der CLS ein numerischer Score, der den Grad der Aktivität von Steuerelementen qualifiziert. Wie im Fall der beiden vorhergehenden Metriken gibt es auch hier die in Abbildung 7 gezeigte Grafik, die den für gute PageRank-Platzierungen erforderlichen Bereich beschreibt.

Abb. 7: Je weniger Bewegung, desto zufriedener ist Google

Für die eigentliche Ermittlung des CLS-Werts setzt Google dann auf ein fliegendes Fenster – nach jeder ersten Änderung läuft die Erfassungs-Engine insgesamt 5 Sekunden lang mit, um die eigentlichen Änderungen nach dem in Abbildung 8 gezeigten Schema zu berechnen.

Abb. 8: Googles CLS-Berechnung erfolgt in einem zweistufigen Prozess

Im Hintergrund arbeitet dabei die folgende Formel, die zwei Werte kombiniert: Layout Shift Score = Impact Fraction * Distance Fraction.Hinter dem Begriff Impact Fraction verbirgt sich in der Welt von Google der Grad der Intensität der Veränderung. Im Fall unserer in der Abbildung 9 gezeigten Struktur wurde ein 50 Prozent des Bildschirms belegendes Element nach unten verschoben, der gesamte berührte Bereich ist deshalb 75 Prozent. Im Fall der Formel würden wir also einen Wert von 0,75 ansetzen müssen. Hinter der Distance Fraction verbergen sich dann Informationen darüber, wie weit sich die betroffenen Elemente am Bildschirm bewegt haben. Dazu ermittelt Google im ersten Schritt, welche der beiden Bildschirmachsen größer ist – im Fall unserer Beispielabbildung wäre das die Höhe. Im nächsten Schritt wird (siehe violetter Pfeil) festgestellt, wie weit sich das Element bewegt hat. In unserem Fall haben wir uns um 25 Prozent der Höhe weiterbewegt, weshalb der Distance-Fraction-Wert 0,25 ist. Aus der Multiplikation folgt dann der endgültige Wert 0,1875.

Abb. 9: Diese Grafik hilft bei der Veranschaulichung des Berechnungsprozesses

CLS optimieren

In der Theorie ist die Optimierung von CLS einfach: Wer alle Animationen deaktiviert, hat einen Score von null. In der Praxis sind Animationen allerdings spätestens seit dem iPhone integraler Bestandteil der User Experience, an den sich sogar Google nicht heranwagt. Unter [7] findet sich deshalb eine Liste von Kriterien, um Google-korrekte Animationen zu realisieren. Die mit Abstand einfachste Methode zur Bekämpfung von CLS-bezogenen Problemen besteht darin, alle Änderungen in der Struktur der Layouts 500 ms nach einer Benutzereingabe durchzuführen – innerhalb dieser Zeit erfolgende Änderungen werden von Google nicht zur Berechnung herangezogen. Eine weitere empfehlenswerte Strategie ist das Mitliefern von Größeninformationen inImage-Tags – diese an sich seit langer Zeit geläufige Vorgehensweise wurde einige Zeit durch CSS-Stylesheets verdrängt, führt aber in heutigen Browser-Layout-Engines dazu, dass die Anordnung der Elemente schon vor dem eigentlichen Herunterladen der Bilddateien festgelegt werden kann:

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />

Ein weiteres häufiges Ärgernis betrifft Werbebibliotheken, die im Rahmen der Einblendung der Werbung das Layout verändern. An dieser Stelle empfiehlt Google das Einfügen von Platzhalterelementen mit fixer Größe, die von der Bibliothek dann – ohne Veränderung der Position der restlichen Elemente am Bildschirm – nur noch mit dem anzuzeigenden Werbebanner befüllt werden müssen. Zu guter Letzt bietet sich die Nutzung der unter [8] im Detail beschriebenen CSS-Transformationen an. Sie ermöglichen die Veränderung der Position eines Elements auf dem Bildschirm in vielen Fällen ohne Erhebung eines CLS-Scores. Warum eine durchtransformverursachte Layoutveränderung für den Benutzer weniger ärgerlich sein soll, ist dem Autor nicht klar – Googles Wege sind manchmal unergründlich.

Messung Googlescher Performanceparameter

Nach diesen technischen Überlegungen zum Aufbau der Web-Vitals-Metriken wollen wir dazu übergehen, die für unsere Webprojekte relevanten Versionen der Daten zu erfassen. Als wichtigste Datenquelle dient der weiter oben genannte Browser Chrome. Google exponiert die vom Browser zurückgelieferten Informationen im unter [9] bereitstehenden PageSpeed-Dienst. Er lässt sich mit einem beliebigen URL füttern und liefert danach wie inAbbildung 10gezeigt diverse Informationen zum Zustand.

Abb. 10: Die Platzhalterwebseite des Autors erscheint logischerweise schnell auf dem Bildschirm

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Google nutzt die Web Vitals auch, um Webdesigner zur Auseinandersetzung mit den hauseigenen, in der Cloud lebenden Big-Data-Verarbeitungswerkzeugen zu zwingen. Eine genauere Besprechung der unter [10] zusammengefassten Dienste würde den Rahmen dieses Artikels sprengen. Da die Quelle der Daten die Chrome-eigene Rendering-Engine ist, dürfte es nicht verwundern, dass das lokale Analysewerkzeug ebenfalls in den Chrome Developer Tools lebt. Spezifisch handelt es sich und um die unter [11] bereitstehende Light House Engine, die in Desktopversionen von Google Chrome automatisch als Teil der Developer Tools eingebunden ist. Um sie zu finden, müssen Sie in das Audits-Tab wechseln, wo Sie ein Leuchtturmpiktogramm samt der Möglichkeit zur Auswahl der durchzuführenden Tests angeboten bekommen. Da das permanente manuelle Öffnen des Browsers in Arbeit ausartet, bietet Google alternativ auch eine in der Node Runtime lebende Version des Produkts an. Zu ihrer Nutzung müssen Sie im ersten Schritt ebenfalls Google Chrome für den Desktop herunterladen und können das Treibermodul danach nach folgendem Schema unter Nutzung der npm-Paketverwaltung auf ihren Rechner holen:

npm install -g lighthouse

Ist das Arbeiten mit Developer Tools und npm zu kompliziert, bietet Google alternativ dazu auch eine Chrome-Erweiterung an. Das unter [12] bereitstehende Produkt integriert sich wie jedes andere Browser-Plug-in in Ihre Chrome-Installation und blendet danach neben der Adresszeile ein farbiges Symbol ein. Wer es anklickt, erhält ein Pop-up-Fenster mit Informationen über die drei Core Web Vitals. Beachten Sie bei der Nutzung all dieser Werkzeuge allerdings, dass sie immer nur einen Schnappschuss der aktuellen Performance der Webseite auf dem vorliegenden Rechner liefern können – hat das Zielsystem des Anwenders beispielsweise weniger RAM oder eine schlechtere Internetverbindung, sind schlechtere Werte durchaus vorstellbar.

Analyse en passant

Die Durchführung von Analysen auf der Workstation des Entwicklers mag für im Web befindliche Produkte brauchbare Ergebnisse liefern – schöner wäre es allerdings, wenn man die Intelligenz direkt im Rahmen des Ladens einer (zu testenden) Webseite zur Ausführung bringen könnte. Google begegnet diesem Begehr durch eine Gruppe von Bibliotheken, die verschiedene zur Web-Vitals-Erfassung vorgesehene Signale exponieren. Die mit Abstand wichtigste Bibliothek ist dabei die Web Vitals Engine, die verschiedene Arten der Metrikexponierung erlaubt [13]. Im Hintergrund stehen dabei immer die drei folgenden Methoden, deren Aufruf zur Ausgabe von Informationen in die Kommandozeile zumindest auf den ersten Blick gewöhnungsbedürftig aussieht:

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Des Pudels Kern ist, dass die Methoden als Parameter eine Implementierung des onReport-Callbacks erwarten – in modernen Browsern wird diese Bedingung von console.log erfüllt, weshalb der hier abgedruckte Code zur Ausgabe der Statusinformationen in der Debuggerkonsole des Browsers führen würde. Wichtig ist in diesem Zusammenhang, dass die Reporter-Funktionen der Bibliothek pro Webseitenladeprozess immer nur einmal aufgerufen werden dürfen. Sie erzeugen im Hintergrund diverse Observer-Instanzen, die sonst zu Speicherlecks führen. Begehren Sie permanente Aktualisierung, erfolgt der Aufruf der jeweiligen Methode nach folgendem Schema:

getCLS(console.log, true);

Derartige Aufrufe sind zum Beispiel deshalb sinnvoll, weil sich Werte wie CLS über die Laufzeit der Webseite verändern – auf diese Art und Weise erhalten Sie regelmäßige Aktualisierungen frei Haus geliefert. Die Bibliothek steht in mehreren Varianten zur Verfügung, neben einem per npm direkt in den Build-Prozess implantierbaren Kandidaten können Sie auch auf aus CDNs direkt ins HTML herunterladbare Versionen setzen. Die Bibliothek selbst ist übrigens nur ein Wrapper um eine Gruppe von Browser-APIs, die Google mittlerweile durch das W3C spezifizieren ließ. Die APIs für den Largest Contentful Paint [14] und den FID [15] – bei der W3C spricht man hier lieber von Event Timing API – sind mittlerweile offizielle Community-Drafts. Für CLS ist die Version derzeit nur in Form des GitHub-Repositorys einsehbar [16]. Über die Frage, welche der beiden Bibliotheken bzw. Vorgehensweisen besser ist, lässt sich hervorragend diskutieren. Der Autor würde allerdings eher zur Google-Bibliothek raten, schon deshalb, weil sie ob der Implementierung der diversen Design Patterns zur Datenübergabe das Einsammeln und Weiterverarbeiten der Performancedaten beschleunigt.

Quo vadis?

Fragt man einen Android-Entwickler nach seiner ehrlichen ersten Reaktion auf das Auftauchen eines Android-Updates, fällt diese so gut wie immer negativ aus. Google gibt und Google nimmt – dieses alte Sprichwort ist immerdar gültig. Im Fall der Core Web Vitals gilt, dass die auf den ersten Blick kontrollierend wirkenden Parameter – zumindest in den meisten Fällen – auch im Interesse Ihrer User und somit am Ende im Interesse Ihrer Profitabilität sind. Die erste Amtshandlung eines Webdesigners sollte darin bestehen, seine Web-Properties mit den hier besprochenen Werkzeugen zu beschnüffeln – wer schlechte Performancewerte aufweist, ist (auch im Interesse der Konversionsrate) immer gut beraten, diese zu verbessern. In diesem Sinne wünscht Ihnen der Autor diesmal nicht gut, sondern schnell Code!